We already write a similar output in conversation, and that's enough

…ction in such case

If we're already about to fail because of a timeout don't cleanup the
transaction because we may end up stopping ongoing conversations which
will lead to a panic, without clear explaination

This is an expectation, not really something we're doing in the test so
change the value as expected

Since we are sharing the daemon we should not reuse the same user
multiple time, so generate them based on the test name to avoid even
manual clashes

…th phase

In gdm when the authentication stage is changed we reset the currently
svaed states, so do it also in the integration test mock to respect what
the UI would do

Sometimes we may want to respond to a specific gdm event with multiple
poll responses, to allow this, without refactor the world, we can just
create a simple fake event and use its type as a counter for the events
we want to group.

When preceding events with this fake event, then the following N events
will be added to the poll responses

Cancellation needs to be possible everytime we're in challenge mode, but
this is handled already by the authentication backend so don't bother
adding the logic here.

Since in this way we'll prevent being able to cancel authentications
that are in "wait" state and so when we're not anymore waiting for user
authentication request, but only for the broker reply.

After this happens we're gonna receive a further start authentication
event, so we need to stop considering the model being in auth phase

When waiting we may want to be able to cancel it, so support it